home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / iso / 8650_1.asc < prev    next >
Text File  |  1992-12-23  |  69KB  |  1,230 lines
  1.          Recommendation X.227
  2.            ASSOCIATION CONTROL PROTOCOL SPECIFICATION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT 
  3.                                                APPLICATIONS 1
  4.                                          (Melbourne, 1988) 
  5.                The CCITT,
  6.          considering
  7.                (a)    that Recommendation  X.200  defines  the  Reference  Model  of  Open
  8.          Systems Interconnection for CCITT applications;
  9.                (b)    that Recommendation X.208 specifies  Abstract  Syntax  Notation  One
  10.          (ASN.1) for the specification of the abstract syntax of protocols;
  11.                (c)    that Recommendation X.209 specifies the  basic  encoding  rules  for
  12.          Abstract Syntax Notation One;
  13.                (d)    that Recommendation X.210 defines the Open  Systems  Interconnection
  14.          (OSI) layer service definition conventions;
  15.                (e)    that Recommendation X.215 defines  the  Session  service  definition
  16.          for Open Systems Interconnection for CCITT applications;
  17.                (f)     that  Recommendation  X.216  defines   the   Presentation   service
  18.          definition of Open Systems Interconnection for CCITT applications;
  19.                (g)  that  Recommendation  X.217  defines   Association   Control   service
  20.          definition for Open Systems Interconnection for CCITT applications;
  21.                (h)     that  Recommendation  X.220  specifies  the  use  of  X.200  series
  22.          protocols in CCITT applications;
  23.                (i)    that Recommendation X.410-1984 specifies  the  protocol  for  Remote
  24.          Operation and Reliable Transfer Server for Message Handling Systems; and
  25.                (j)    that there is a need for  common  Association  Control  support  for
  26.          various applications,
  27.          unanimously declares
  28.                that this Recommendation defines the Association Control  specification  of
  29.          Open Systems Interconnection for CCITT applications as given  in  the  Scope  and
  30.          Field of Application.
  31.                                                   CONTENTS 
  32.          0      Introduction
  33.          1      Scope and field of application
  34.          2      References
  35.          3      Definitions
  36.                3.1    Reference Model definitions
  37.                3.2    Naming and addressing definitions
  38.                3.3    Service conventions definitions
  39.                3.4    Presentation service definitions
  40.                3.5    ACSE service definitions
  41.                3.6    Association Control protocol specification definitions
  42.          4      Symbols and abbreviations
  43.                4.1    Data units
  44.                4.2    Types of application-protocol-data-units
  45.                4.3    Other abbreviations
  46.          5      Conventions
  47.          6      Overview of the protocol
  48.                6.1    Service provision
  49.                6.2    Use of the presentation-service
  50.                6.3    Relationship to the session-service
  51.                6.4    Model
  52.          7      Elements of procedure
  53.                7.1    Association establishment
  54.                7.2    Normal release of an association
  55.                7.3    Abnormal release of an association
  56.                7.4    Rules for extensibility
  57.          8      Mapping to the presentation-service
  58.                8.1    Association establishment (normal mode)
  59.                8.2    Normal release of an association (normal mode)
  60.                8.3    Abnormal release of an association (normal mode)
  61.  
  62.          1  Recommendation X.227 and ISO 8650   [Information  processing  systems  -  Open  Systems
  63.            Interconnection - Protocol specification for the Association Control  Service  Element]
  64.            were developed in close collaboration and  are  technically  aligned,  except  for  the
  65.            differences noted in Appendix I. 
  66.  
  67.  
  68.  
  69.  
  70.                                                                       Rec. X.227       PAGE1
  71.  
  72.  
  73.                8.4    Association establishment (X.410-1984 mode)
  74.                8.5    Normal release of an association (X.410-1984 mode)
  75.                8.6  Abnormal release of an association (X.410-1984 mode)
  76.          9      Structure and encoding of ACSE APDUs
  77.          10     Conformance
  78.                10.1   Statement requirements
  79.                10.2   Static requirements
  80.                10.3   Dynamic requirements
  81.          Annex A - ACPM state table for normal mode of operation
  82.                A.1    General
  83.                A.2    Conventions
  84.                A.3    Actions to be taken by the ACPM
  85.                    A.3.1 Invalid intersections
  86.                    A.3.2 Valid intersections
  87.                A.4    Relationship to Presentation and other ASEs
  88.          Annex B - ACPM state table for X.410-1984 mode of operation
  89.                B.1  General
  90.                B.2    Conventions
  91.                B.3    Actions to be taken by the ACPM
  92.                    B.3.1  Invalid intersections
  93.                    B.3.2  Valid intersections
  94.                B.4    Relationship to Presentation and other ASEs
  95.          Appendix I -  Differences  between  Recommenation  X.227  and  ISO  International
  96.          Standard 8650
  97.          Appendix II - Summary of Assigned Object Identifier Values
  98.          0      Introduction
  99.          0.1    This Recommendation is  one  of  a  set  of  Recommendations  produced  to
  100.          facilitate the interconnection of information processing systems. It  is  related
  101.          to other Recommendations in the set as defined by the Reference  Model  for  Open
  102.          Systems Interconnection (X.200). The  Reference  Model  subdivides  the  area  of
  103.          standardization for interconnection into a series  of  layers  of  specification,
  104.          each of manageable size.
  105.          0.2    The goal of Open Systems Interconnection is to allow, with  a  minimum  of
  106.          technical agreement outside the interconnection standards, the interconnection of
  107.          information processing systems:
  108.                - from different manufacturers;
  109.                - under different managements;
  110.                - of different levels of complexity; and
  111.                - of different technologies.
  112.          0.3    This Recommendation specifies the protoc l  for  the  application-service-
  113.          element for application-association  control:  the  Association  Control  Service
  114.          Element (ACSE).  The  ACSE  provides  services  for  establishing  and  releasing
  115.          application-associations. These services are intended to be applicable to a  wide
  116.          range of application-process communication requirements.
  117.          0.4    This Recommendation includes  two  annexes  which  describe  the  protocol
  118.          machine of ACSE in terms of a state table for normal mode of  operation  and  for
  119.          X.410-1984 mode of operation.  This  protocol  machine  is  referred  to  as  the
  120.          Association Control Protocol Machine (ACPM).
  121.          0.5    The protocol defined in this Recommendation is also governed by the use of
  122.          the presentation-service (X.216) and the session-service (X.215).
  123.          0.6    Quality of Services (QOS) is a parameter of the A-ASSOCIATE service.  Work
  124.          is still in progress to provide an integrated treatment of QOS across all of  the
  125.          layers of the OSI Reference Model and to ensure that the individual treatments in
  126.          each layer service satisfy overall QOS objectives in a consistent  manner.  As  a
  127.          consequence, a change may be made to this Recommendation at a  later  time  which
  128.          reflects further QOS developments and integration.
  129.          1      Scope and field of application
  130.                The procedures defined in this Recommendation are applicable  to  instances
  131.          of communication between systems which wish to interconnect in  an  open  systems
  132.          interconnection environment. This Recommendation specifies:
  133.                a)  procedures for the transfer of information relating to the application 
  134.                   association control between application entities; and
  135.                b)  the abstract syntax for the representation of the ACSE APDUs.
  136.                The ACSE procedures are defined in terms of:
  137.  
  138.  
  139.  
  140.  
  141.  
  142.          PAGE22        Rec. X.227
  143.  
  144.  
  145.                a)  the interactions between peer ACSE protocol machines through the use of
  146.          presentation-services; and
  147.                b)  the interaction between an ACSE protocol machine and its service user.
  148.                This Recommendation also specifies  conformance  requirements  for  systems
  149.          implementing these procedures. It does not contain tests which  can  be  used  to
  150.          demonstrate conformance.
  151.          2      References
  152.          Recommendation X.200 -  Reference Model of Open Systems Interconnection for CCITT
  153.                            applications (see also ISO 7498-1).
  154.          Recommendation X.208 -  Specification of Abstract Syntax Notation One  (see  also
  155.          ISO 8824).
  156.          Recommendation X.209 -  Basic Encoding Rules for  Abstract  Syntax  Notation  One
  157.          (see also ISO 8825).
  158.          Recommendation X.210 -  OSI Layer Service Definition Conventions (see also ISO TR
  159.          8509).
  160.          Recommendation  X.215  -    Session   service   definition   for   Open   Systems
  161.                            Interconnection for CCITT applications (see also ISO  8326  and
  162.                            ISO 8326 Addendum 2).
  163.          Recommendation  X.216  -   Presentation  service  definition  for  Open   Systems
  164.                            Interconnection for CCITT applications (see also ISO 8822).
  165.          Recommendation X.217 -  Association Control service definition for  Open  Systems
  166.                            Interconnection for CCITT applications (see also ISO 8649).
  167.          Recommendation  X.225  -   Session  protocol  specification  for   Open   Systems
  168.                            Interconnection for CCITT applications (see also ISO  8327  and
  169.                            ISO 8327 Addendum 2).
  170.          Recommendation X.410 -  CCITT Recommendation  X.410:  Message  Handling  Systems:
  171.                            Remote Operations and Reliable Transfer Server (1984).
  172.          ISO  7498-3           -      Information  processing  systems  -   Open   Systems
  173.                            Interconnection - Basic Reference Model - Part  3:  Naming  and
  174.                            Addressing.
  175.          3      Definitions
  176.          3.1    Reference Model definitions
  177.          This Recommendation is based on the concepts developed in X.200 and makes use  of
  178.          the following terms defined in it:
  179.                a)  application Layer;
  180.                b)  application-process;
  181.                c)  application-entity;
  182.                d)  application-service-element;
  183.                e)  application-protocol-data-unit;
  184.                f )    application-protocol-control-information;
  185.                g)  presentation-service;
  186.                h)  presentation-connection;
  187.                i)  session-service;
  188.                j )    session-service protocol; and
  189.                k)  session-connection.
  190.          3.2    Naming and addressing definitions
  191.                This Recommendation makes use of the following terms defined  n  ISO  7498-
  192.          3:
  193.                a)  application-process title;
  194.                b)  application-entity qualifier;
  195.                c)  application-entity title2 
  196.                d)  application-process invocation-identifier;
  197.                e)  application-entity invocation-identifier; and
  198.                f )    presentation address.
  199.          3.3    Service conventions definitions
  200.                This Recommendation makes use of the following terms defined in X.210:
  201.                a)  service-provider;
  202.                b)  service-user;
  203.                c)  confirmed service;
  204.                d)  non-confirmed service;
  205.                e)  provider-initiated service;
  206.  
  207.          2  As defined in ISO 7498-3, an application-entity title is composed  of  an  application-
  208.            process title and an application-entity qualifier. The ACSE protocol provides  for  the
  209.            transfer of an application-entity title value by the transfer of its component values.
  210.  
  211.  
  212.  
  213.  
  214.                                                                       Rec. X.227       PAGE1
  215.  
  216.  
  217.                f )    primitive;
  218.                g)  request (primitive);
  219.                h)  indication (primitive);
  220.                i)  response (primitive); and
  221.                j )    confirm (primitive).
  222.          3.4    Presentation service definitions
  223.                This Recommendation makes use of the following terms defined in X.216:
  224.                a)  abstract syntax;
  225.                b)  abstract syntax name;
  226.                c)  default context;
  227.                d)  defined context set;
  228.                e)  functional unit [presentation];
  229.                f )    normal mode [presentation];
  230.                g)  presentation context;
  231.                h)  presentation data value; and
  232.                i)  X.410-1984 mode [presentation].
  233.          3.5    ACSE service definitions
  234.                This Recommendation makes use of the following terms defined in X.217.
  235.                a)  application-association; association;
  236.                b)  application context;
  237.                c)  Association Control Service Element;
  238.                d)  ACSE service-user;
  239.                e)  ACSE service-provider;
  240.                f )    requestor;
  241.                g)  acceptor;
  242.                h)  association-initiator;
  243.                i)  association-responder;
  244.                j )    normal mode;
  245.                k)  X.410-1984 mode; and
  246.                j)  disrupt.
  247.          3.6    Association Control protocol specification definitions
  248.                The following terms are introduced in this Recommendation.
  249.          3.6.1  Association Control Protocol Machine
  250.                The protocol machine for the Association Control Service Element  specified
  251.          in this Recommendation.
  252.          3.6.2  requesting Association Control Protocol Machine
  253.                The  Association  Control  Protocol  Machine  whose  service-user  is   the
  254.          requestor of a particular Association Control Service Element service.
  255.          3.6.3  accepting Association Control Protocol Machine
  256.                The  Association  Control  Protocol  Machine  whose  service-user  is   the
  257.          acceptor for a particular Association Control Service Element service.
  258.          4      Symbols and abbreviations
  259.          4.1    Data units
  260.                APDU application-protocol-data-unit
  261.          4.2    Types of application-protocol-data-units
  262.                The following abbreviations have been giv n  to  the  application-protocol-
  263.          data-units defined in this Recommendation.
  264.                AARQ   A-ASSOCIATE-REQUEST application-protocol-data-unit
  265.                AARE   A-ASSOCIATE-REQUEST application-protocol-data-unit
  266.                RLRQ   A-RELEASE-REQUEST application-protocol-data-unit
  267.                RLRE   A-RELEASE-RESPONSE application-protocol-data-unit
  268.                ABRT   A-ABORT application-protocol-data-unit
  269.          4.3    Other abbreviations
  270.                The following abbreviations are used in this Recommendation:
  271.                ACPM   Association Control Protocol Machine
  272.                ACSE   Association Control Service Element
  273.                AE      application-entity
  274.                AP      application-process
  275.                APCI   application-protocol-control-information
  276.                ASE    application-service-element
  277.                ASN.1  Abstract Syntax Notation One
  278.                OSI        Open Systems Interconnection
  279.                QOS    quality of service
  280.          5      Conventions
  281.  
  282.  
  283.  
  284.  
  285.  
  286.          PAGE22        Rec. X.227
  287.  
  288.  
  289.          5.1    This Recommendation employs a tabular presentation of its APDU fields.  In
  290.          S 7, tables are presented for each ACSE APDU. Each field is summarized using  the
  291.          following notation:
  292.                M   presence is mandatory
  293.                O   presence is ACPM option
  294.                U   presence is ACSE service-user option
  295.                req    source is related request primitive
  296.                ind    sink is related indication primitive
  297.                rsp    source is related response primitive
  298.                cnf    sink is related confirm primitive
  299.                sp  source or sink is the ACPM
  300.          5.2    The structure of each ACSE SPDU is specified in S  9  using  the  abstract
  301.          syntax notation of ASN.1 (X.208).
  302.          6      Overview of the protocol
  303.          6.1    Service provision
  304.                The  protocol  specified  in  this  Recommendation  provides  the  services
  305.          defined in X.217. These services are listed in Table 1/X.227.  For  a  particular
  306.          association, the ACSE services operate either in the normal mode or in the X.410 
  307.          1984 mode. The mode of operation is determined by the Mode paramet r  on  the  A-
  308.          ASSOCIATE request primitive.
  309.                                                 TABLE 1/X.227
  310.                                                Service summary
  311.                     Service                           Type
  312.          A-ASSOCIATE                               Confirmed
  313.          A-RELEASE                                 Confirmed
  314.          A-ABORT                                 Non-confirmed
  315.          A-P-ABORT                            Provider-initiated 
  316.                6.2    Use of the presentation-service
  317.          6.2.1  ACE's use of the presentation-service (X.216) is determined by ACSE's mode
  318.          of operation for an association as specified below:
  319.                a)  ACSE normal mode: The ACPM uses the normal mo e  of  the  presentation-
  320.          service. The  ACPM  uses  the  presentation-service  Kernel  functional  unit  to
  321.          exchange its APCI and, optionally,  ACSE  service-user  information  (i.e.,  ACSE
  322.          APDUs) with its peer. The use of additional presentation-service functional units
  323.          is an ACSE service-user choice. This choice does not affect the operation of  the
  324.          ACPM.
  325.                b)  ACSE X.410-1984  mode:  The  ACPM  uses  the  X.410-1984  mode  of  the
  326.          presentation-service. Only the Kernel functional unit is available when using the
  327.          presentation-service X.410-1984 mode. In this mode, the ACPM  does  not  exchange
  328.          its own APCI with its peer. It simply passes through information supplied  to  it
  329.          by the ACSE service-user or by the presentation-service.
  330.          6.2.2  This Recommendation assumes that the ACPM  s  the  sole  user  of  the  P-
  331.          CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT services. The ACSE neither uses  nor
  332.          constrains the use of any other presentation service.
  333.          6.2.3   When  supported  by  version  1  of  the  session-protocol  (X.225),  the
  334.          presentation-service  is  subject  to  length  restrictions  for  its   user-data
  335.          parameters. This Recommendation assumes that a local mechanism detects violations
  336.          of these constraints and makes the ACSE service-user aware of them.  An  encoding
  337.          optimization is specified for A-ABORT to mitigate this problem (see S 7.3.3.1).
  338.          6.3    Relationship to the session-service
  339.          6.3.1  The functional units of  the  session-service  (X.215)  required  for  the
  340.          session-connection  which  support  the  presentation-connection  (that  in  turn
  341.          supports the association) are determined by the A-ASSOCIATE service requestor and
  342.          acceptor. They accomplish this using the Session Requirements parameter on the A 
  343.          ASSOCIATE primitives.
  344.          6.3.2  The rules of the session-service affect the operation of the ACPM and  its
  345.          service-user. The ACSE service-user must be  aware  of  these  constraints.  This
  346.          Recommendation assumes that a local mechanism enforces  them.  Some  examples  of
  347.          session-service constraints which affect the ACSE service-user are:
  348.                a)  the availability of negotiated release; and
  349.                b)  the possibility of release collisions.
  350.          6.4    Model
  351.          6.4.1  The Association control Protocol Machine (ACPM) is  modeled  as  a  finite
  352.          state machine whose specification is  given  in  this  Recommendation.  The  ACPM
  353.  
  354.  
  355.  
  356.  
  357.  
  358.                                                                       Rec. X.227       PAGE1
  359.  
  360.  
  361.           communicates with its service-user  by  means  of  the  ACSE  service  primitives
  362.           defined in X.217. The ACPM communicates with its presentation service-provider by
  363.           means of the presentation services defined in X.216.
  364.           6.4.2  The ACPM is driven by the receipt of input events from i s  ACSE  service-
  365.           user and from its presentation service-provider for the underlyi g  presentation-
  366.           connection which supports the association. The input events from the ACSE service
  367.           user are ACSE  request  and  response  primitives.  The  input  events  from  its
  368.           presentation service-provider are presentation indication and confirm primitives.
  369.           6.4.3  The ACPM responds  to  input  events  by  issuing  output  events  to  its
  370.           presentation-service-provider and to its ACSE service-user. The output events  to
  371.           its  presentation-service-provider  are   presentation   request   and   response
  372.           primitives. The output events to its ACSE service-user are  ACSE  indication  and
  373.           confirm primitives.
  374.           6.4.4  The receipt of an input event, the generation of  dependent  actions,  and
  375.           the resultant output event are considered to be an indivisible action.
  376.           6.4.5  During the establishment of an association between two AEs, the  existence
  377.           of invocations of both the requesting and responding AEs is  presumed.  How  they
  378.           are created is outside of the scope of this Recommendation.
  379.           6.4.6  A new invocation of an ACPM is employed upon the receipt of an A-ASSOCIATE
  380.           request primitive or a  P-CONNECT  indication  primitive.  Each  such  invocation
  381.           controls exactly one association.
  382.                 Note - Each association may be identified in  an  end  system  by  a  local
  383.           mechanism  so  that  the  ACSE  service-user  and  the  ACPM  can  refer  to  the
  384.           association.
  385.           6.4.7  The ACPM is modeled to operate in either one of  two  modes  for  a  given
  386.           association: the normal mode, and the X.410-1984 mode, as specified below.
  387.                 a)  When operating in the normal mode, an APCM communicates with  its  peer
  388.                      ACPM in support of an  association  by  transferring  ACSE  application
  389.                      protocol data u   s  (APDUs)  defined  in  S  93.  An  ACSE  APDU  is
  390.                      transferred as a presentation data value in the User Data parameter  of
  391.                      the presentati n  primitive  used  on  the   underlying   presentation-
  392.                      connection.
  393.                 b)  When operating in the X.410-1984 mode, an ACPM does not  transfer  ACSE
  394.                      APDUs with its peer. In this situation, the sending  and  receiving  of
  395.                      presentation primitives are in themselves significant protocol events.
  396.           7      Elements of procedure
  397.                 The ACSE protocol consists of the following procedures:
  398.                 a)  association establishment;
  399.                 b)  normal release of an association; and
  400.                 c)  abnormal release of an association.
  401.                 In this clause, a summary  of  each  of  these  elements  of  procedure  is
  402.           presented. This consists of a summary of the relevant  APDUs,  and  a  high-level
  403.           overview of the relationship between the ACSE services, the APDUs  involved,  and
  404.           the presentation service which  is  used.  The  use  of  the  parameters  of  the
  405.           presentation primitives are described in S 8.
  406.                 A detailed specification  of  the  ACSE  APDUs  using  the  ASN.1  notation
  407.           (X.208) is described in S 9. Annex A specifies the state table for the  ACPM  for
  408.           normal mode of operation. Annex B specifies the state  table  for  the  ACPM  for
  409.           X.410-1984 mode of operation.
  410.           7.1    Association establishment
  411.           7.1.1  Purpose
  412.                 The  association  establishment  procedure  is   used   to   establish   an
  413.           association between two AEs. It supports the A-ASSOCIATE service.
  414.           7.1.2  APDUs used
  415.                 The  association  establishment  procedure  uses  the   A-ASSOCIATE-REQUEST
  416.           (AARQ) and the A-ASSOCIATE-RESPONSE (AARE) APDUs. The fields of the AARQ PDU  are
  417.           listed in Table 2/X.227. The fields of the AARE APDU are listed in Table 3/X.227.
  418.                                                 TABLE 2/X.227 
  419.                                                AARQ APDU fields
  420.                    Field name            Presence    Source      Sink 
  421.           Protocol Version                   O         sp        sp 
  422.           Application Context Name           M        req       ind 
  423.           Calling AP Title                   U        req       ind 
  424.           Calling AE Qualifier               U        req       ind 
  425.           Calling AP Invocation-             U        req       ind 
  426.           identifier                      
  427.           3  This is true with one exception. If the association is supported by version 1   of  the
  428.           session-protocol (X.225), the requesting ACPM does not pass ACSE APCI as user data on a P 
  429.           U-ABORT request primitive. The absence of ACSE APCI in this situation does not imply  that
  430.           the association is operating in the X.410-1984 mode (see SS 6.4.6 and 7.3.3.1).
  431.  
  432.  
  433.  
  434.  
  435.           PAGE22        Rec. X.227
  436.  
  437.  
  438.           Calling AE Invocation-             U        req       ind 
  439.           identifier                      
  440.           Called AP Title                    U        req       ind 
  441.           Called AE Qualifier                U        req       ind 
  442.           Called AP Invocation-              U        req       ind 
  443.           identifier                      
  444.           Called AE Invocation-              U        req       ind 
  445.           identifier                      
  446.           Implementation information         O         sp         sp 
  447.           User information                   U        req       ind 
  448.  
  449.                                                  TABLE 3/X.227
  450.                                                AARE APDU fields
  451.                    Field name            Presence    Source    
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.                                                                        Rec. X.227       PAGE1
  508.  
  509.  
  510.                                                                   Sink 
  511.           Protocol Version                   O         sp         sp 
  512.           Application Context Name           M        rsp       cnf 
  513.           Responding AP Title                U        rsp       cnf 
  514.           Responding AE Qualifier            U        rsp       cnf 
  515.           Responding AP Invocation-          U        rsp       cnf 
  516.           identifier                      
  517.           Responding AE Invocation-          U        rsp       cnf 
  518.           identifier                      
  519.           Result                             M       rsp/sp      cnf 
  520.           Result Source - Diagnostic         M       rsp/sp      cnf 
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.           PAGE22        Rec. X.227
  580.  
  581.  
  582.          Implementation Information         O         sp         sp 
  583.          User Information                   U        rsp       cnf 
  584.                7.1.3  Association establishment procedure
  585.                This procedure is driven by the following events:
  586.                a)  an A-ASSOCIATE request primitive from the requestor;
  587.                b)  an AARQ APDU as user data on a P-CONNECT indication primitive;
  588.                c)  an A-ASSOCIATE response primitive from the acceptor; and
  589.                d)  a P-CONNECT confirm primitive (that may or  may  not  contain  an  AARE
  590.          APDU).
  591.          7.1.3.1   A-ASSOCIATE request primitive
  592.          7.1.3.1.1 The requesting ACPM forms an AARQ APDU from parameter values of t e  A-
  593.          ASSOCIATE  request  primitive  and   optionally,   the   Protocol   Version   and
  594.          implementation information. It issues a P-CONNECT request  primitive  also  using
  595.          information from the A-ASSOCIATE request primitive. The User  Data  parameter  of
  596.          the P-CONNECT request primitive contains the AARQ APDU.
  597.          7.1.3.1.2 The requesting ACPM waits for a primitive from the presentation service
  598.          provider and does not accept any other primitive from the requestor other than an
  599.          A-ABORT request primitive.
  600.          7.1.3.2   AARQ APDU
  601.          7.1.3.2.1 The accepting ACPM receives an AARQ APDU from its peer as user data  on
  602.          a P-CONNECT indication primitive.
  603.          7.1.3.2.2 The ACPM determines if the AARQ ADPU is acceptable based on  the  rules
  604.          for extensibility (see S 7.4). If the AARQ APDU is  not  acceptable,  a  protocol
  605.          error results  (see  S  7.3.3.4).  The  association  establishment  procedure  is
  606.          disrupted. An A-ASSOCIATE indication primitive is not issued. The association  is
  607.          not established.
  608.          7.1.3.2.3 The ACPM next inspects the value of the Protocol Version field 4of t 
  609.          AARQ APDU. If the ACPM does not support a common protocol version,  it  forms  an
  610.          AARE APDU with the following assigned fields:
  611.                a)  Protocol Version field (optional) with the value  which  indicates  the
  612.                   protocol version(s) which it could support (see S 7.1.5.1);
  613.                b)  Application Context Name field with the same value as on the AARQ APDU;
  614.                c)  Result field with the value ╗rejected (permanent)½; and
  615.                d)  Result Source-Diagnostic field with the values ╗ACSE  service-provider½
  616.                   and ╗not common ACSE version½.
  617.                In this case, the ACPM sends the AARE APDU as  user  data  on  a  P-CONNECT
  618.          response primitive with a Result parameter which has the value ╗user  rejection½.
  619.          The ACPM does not issue an A-ASSOCIATE indication primitive. The  association  is
  620.          not established.
  621.          7.1.3.2.4 If the P-CONNECT indication primitive and its AARQ APDU are acceptable,
  622.          the ACPM issues an A-ASSOCIATE indicati n  primitive  to  the  acceptor.  The  A-
  623.          ASSOCIATE indication primitive parameters are derived from the AARQ APDU and  the
  624.          P-CONNECT indication primitive. The ACPM waits for a primitive from the acceptor.
  625.          7.1.3.3   A-ASSOCIATE response primitive
  626.          7.1.3.3.1 When the accepting ACPM receives the  A-ASSOCIATE  response  primitive,
  627.          the Result parameter specifies whether the service-user has accepted or  rejected
  628.          the association. The ACPM forms an  AARE  APDU  using  the  A-ASSOCIATE  response
  629.          primitive parameters. The ACPM sets the Result Source-Diagnostic field  to  ╗ACSE
  630.          service-user½ and the value derived from the Diagnostic parameter of the response
  631.          primitive. The AARE APDU is sent as the User  Data  parameter  on  the  P-CONNECT
  632.          response primitive.
  633.          7.1.3.3.2 If the acceptor accepted the association resquest, the Result parameter
  634.          on the related P-CONNECT  response  primitive  specifies  ╗acceptance½,  and  the
  635.          Result field of the outgoing AARE APDU specifies ╗accepted½. The  association  is
  636.          established.
  637.          7.1.3.3.3 If the acceptor rejected the association request, the Result  parameter
  638.          on the related P-CONNECT response primitive specifies ╗user-rejection½,  and  the
  639.          Result field of the AARE APDU  contains  the  appropriate  rejection  value.  The
  640.          association is not established.
  641.          7.1.3.4   P-CONNECT confirm primitive
  642.          7.1.3.4.1 The requesting ACPM receives a P-CONNECT confirm primitive.
  643.                The following situations are possible:
  644.                a)  the association has been accepted;
  645.  
  646.          4  If the Protocol Version field is not present in the AARQ APDU, version 1 is assumed 
  647.  
  648.  
  649.  
  650.  
  651.                                                                       Rec. X.227       PAGE1
  652.  
  653.  
  654.                b)  the accepting ACPM or the acceptor has rejected the association; or
  655.                c)   the  representation  service-provider   has   rejected   the   related
  656.          presentation connection.
  657.          7.1.3.4.2 If the association was accepted, the P-CONNECT confirm primitive Result
  658.          parameter specifies ╗acceptance½. The User Data parameter contains an AARE  APDU.
  659.          The Result field of the AARE  APDU  specifies  ╗accepted½.  The  requesting  ACPM
  660.          issues an A-ASSOCIATE confirm primitive to the requestor derived from  parameters
  661.          from the P-CONNECT confirm primitive and the AARE APDU. The  A-ASSOCIATE  confirm
  662.          primitive Result parameter specifies ╗accepted½. The association is established.
  663.          7.1.3.4.3 If the association was rejected by either the accepting ACPM or by  the
  664.          acceptor, the related P-CONNECT  confirm  primitive  Result  parameter  specifies
  665.          ╗user-rejection½. The User Data parameter contains an AARE APDU.
  666.          7.1.3.4.4 The requesting ACPM issues an  A-ASSOCIATE  confirm  primitive  to  the
  667.          requestor derived from prameters from the P-CONNECT  confirm  primitive  and  the
  668.          AARE APDU. The A-ASSOCIATE confirm primitive Result parameter indicates ╗rejected
  669.          (transient)½ or ╗rejected (permanent)½. The  Result  Source  parameter  indicates
  670.          ╗ACSE  service-user½  or  ╗ACSE  service-provider½.  The   association   is   not
  671.          established.
  672.          7.1.3.4.5 If the presentation-connection was rejected by the presentation service
  673.          provider, the P-CONNECT confirm primitive Result paramet r  specifies  ╗provider-
  674.          rejection½. In this situation, the User Data field is not  used.  The  requesting
  675.          ACPM issues an A-ASSOCIATE confirm primitive with the Result parameter indicating
  676.          ╗rejected (permanent)½.  The  Result  Source  parameter  indicates  ╗presentation
  677.          service-provider½5  The association is not established.
  678.          7.1.4  Use of the AARQ APDU fields
  679.                The AARQ APDU fields are used by the  requesting  and  accepting  ACPMs  as
  680.          specified below.
  681.          7.1.4.1   Protocol Version
  682.                For the requesting ACPM: The value assigned to  this  field  is  determined
  683.          within the implementation of the ACPM. It is a variable length bit  string  where
  684.          each bit that is set to one indicates the version of ACSE protocol that this ACPM
  685.          supports. Bit 0 represents version 1; bit 1 represents version 2; etc..  Multiple
  686.          bits may be set indicating support of multiple versions. No trailing bits  higher
  687.          than the highest  version  of  this  Recommendation  which  the  requesting  ACPM
  688.          supports are included. That is, the last bit of the string is set to one.
  689.                For the accepting ACPM: The ACPM ignores trailing bits of this field  which
  690.          are higher than the one indicating the  latest  version  of  this  Recommendation
  691.          which it supports.
  692.          7.1.4.2   Application Context Name
  693.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  694.          Application Context Name parameter of the A-ASSOCIATE request primitive.
  695.                For the accepting ACPM: This value is used to determine the  value  of  the
  696.          Application Context Name parameter of the A-ASSOCIATE  indication  primitive,  if
  697.          issued.
  698.          7.1.4.3   Calling AP Title
  699.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  700.          Calling AP Title parameter of the A-ASSOCIATE request primitive.
  701.                For the accepting ACPM: This value is used to determine the  value  of  the
  702.          Calling AP Title parameter of the A-ASSOCIATE indication primitive, if issued.
  703.          7.1.4.4   Calling AE Qualifier
  704.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  705.          Calling AE Qualifier parameter of the A-ASSOCIATE request primitive.
  706.                For the accepting ACPM: This value is used to determine the  value  of  the
  707.          Calling AE Qualifier  parameter  of  the  A-ASSOCIATE  indication  primitive,  if
  708.          issued.
  709.          7.1.4.5   Calling AP Invocation-identifier
  710.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  711.          Calling AP Invocation-identifier parameter of the A-ASSOCIATE request primitive.
  712.                For the accepting ACPM: This value is used  to  derive  the  value  of  the
  713.  
  714.          5  The presentation-service (Rec. X.216) currently does not define a Diagnostic parameter 
  715.            on the P-CONNECT response. However, work is still in progress to provide an  integrated
  716.            treatment of the ╗result½ related parameters across all layers  of  the  OSI  Reference
  717.            Model. As a consequence, a change may be made to this Recommendation at  a  later  time
  718.            that reflects further developments and integration.
  719.  
  720.  
  721.  
  722.  
  723.          PAGE22        Rec. X.227
  724.  
  725.  
  726.          Calling  AP  Invocation-identifier  parameter  of  the   A-ASSOCIATE   indication
  727.          primitive, if issued.
  728.          7.1.4.6   Calling AE Invocation-identifier
  729.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  730.          Calling AE Invocation-identifier parameter of the A-ASSOCIATE request primitive.
  731.                For the accepting ACPM: This value is used  to  derive  the  value  of  the
  732.          Calling  AE  Invocation-identifier  parameter  of  the   A-ASSOCIATE   indication
  733.          primitive, if issued.
  734.          7.1.4.7   Called AP Title
  735.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  736.          Called AP Title parameter of the A-ASSOCIATE request primitive.
  737.                For the accepting ACPM: This value is used to determine the  value  of  the
  738.          Called AP Title parameter of the A-ASSOCIATE indication primitive, if issued.
  739.          7.1.4.8   Called AE Qualifier
  740.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  741.          Called AE Qualifier parameter of the A-ASSOCIATE request primitive.
  742.                For the accepting ACPM: This value is used to determine the  value  of  the
  743.          Called AE Qualifier parameter of the A-ASSOCIATE indication primitive, if issued.
  744.          7.1.4.9   Called AP invocation-identifier
  745.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  746.          Called AP Invocation-identifier parameter of the A-ASSOCIATE request primitive.
  747.                For the accepting ACPM: This value is used to determine the  value  of  the
  748.          Called  AP  Invocation-identifier  parameter  of   the   A-ASSOCIATE   indication
  749.          primitive, if issued.
  750.          7.1.4.10  Called AE Invocation-identifier
  751.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  752.          Called AE Invocation-identifier parameter of the A-ASSOCIATE request primitive.
  753.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  754.          Called  AE  Invocation-identifier  parameter  of   the   A-ASSOCIATE   indication
  755.          primitive, if issued.
  756.          7.1.3.11  Implementation Information
  757.                For the requesting ACPM: The value assigned to  this  field  is  determined
  758.          within the implementation of the ACPM. It contains information  specific  to  the
  759.          individual implementation of that ACPM. It is not used in negotiation. 
  760.                For the accepting ACPM: This field does not affect  the  operation  of  the
  761.          ACPM. Any use depends on  a  common  understanding  between  the  requesting  and
  762.          accepting ACPMs.
  763.          7.1.4.12  User Information
  764.                For the requesting ACPM: This value is determined by the value of the  User
  765.          Information parameter of the A-ASSOCIATE request primitive.
  766.                For the accepting ACPM: This value is used to determine the  value  of  the
  767.          User Information parameter of the A-ASSOCIATE indication primitive, if issued.
  768.          7.1.5  Use of the AARE APDU fields
  769.                The AARE APDU fields are used by the  accepting  and  requesting  ACPMs  as
  770.          specified below.
  771.          7.1.5.1   Protocol Version
  772.                For the accepting ACPM: The value  of  this  field  assigned  by  the  ACPM
  773.          depends on whether the association request is accepted or rejected  by  the  ACPM
  774.          and the acceptor as specified below.
  775.                a)  If the association is accepted, the value assigned by  the  ACPM  is  a
  776.          variable length bit string which indicates the protocol version selected  by  the
  777.          ACPM from those proposed in the AARQ APDU. Only the bit  indicating  the  version
  778.          selected is set to one. That bit is the last bit in the string.
  779.                b)  If the association is rejected, the value assigned by  the  ACPM  is  a
  780.                   variable length bit string which indicates the protocol  version(s)  of
  781.                   this Recommendation which could be supported by the ACPM.
  782.                For the requesting ACPM: The use of the value  in  this  field  depends  on
  783.          whether the association request is accepted or rejected.
  784.                a)  If the association is accepted, this value defines the protocol version
  785.                   of this Recommendation to be used for this association.
  786.                b)  If the association is rejected, the  use  of  this  value  is  a  local
  787.          option.
  788.          7.1.5.2   Application Context Name
  789.                For the  accepting  ACPM:  This  value  determined  by  the  value  of  the
  790.  
  791.  
  792.  
  793.  
  794.  
  795.                                                                       Rec. X.227       PAGE1
  796.  
  797.  
  798.          Application Context Name parameter of the A-ASSOCIATE response primitive.
  799.                For the requesting ACPM: This value is used to determine the value  of  the
  800.          Application Context Name parameter of the A-ASSOCIATE confirm primitive.
  801.          7.1.5.3   Responding AP Title
  802.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  803.          Responding AP Title parameter of the A-ASSOCIATE response primitive.
  804.                For the requesting ACPM: This value is used to determine the value  of  the
  805.          Responding AP Title parameter of the A-ASSOCIATE confirm primitive, if issued.
  806.          7.1.5.4   Responding AE Qualifier
  807.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  808.          Responding AE Qualifier parameter of the A-ASSOCIATE response primitive.
  809.                For the requesting ACPM: This value is used to determine the value  of  the
  810.          Responding AE Qualifier  parameter  of  the  A-ASSOCIATE  confirm  primitive,  if
  811.          issued.
  812.          7.1.5.5   Responding AP Invocation-Identifier
  813.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  814.          Responding AP  Invocation-  identifier  parameter  of  the  A-ASSOCIATE  response
  815.          primitive.
  816.                For the requesting ACPM: This value is used to determine the value  of  the
  817.          Responding  AP  Invocation-identifier  parameter  of  the   A-ASSOCIATE   confirm
  818.          primitive, if issued.
  819.          7.1.5.6   Responding AE Invocation-identifier
  820.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  821.          Responding AE  Invocation-  identifier  parameter  of  the  A-ASSOCIATE  response
  822.          primitive.
  823.                For the requesting ACPM: This value is used to determine the value  of  the
  824.          Responding  AE  Invocation-identifier  parameter  of  the   A-ASSOCIATE   confirm
  825.          primitive, if issued.
  826.          7.1.5.7   Result
  827.                For the accepting ACPM: The value is determined  by  the  ACPM  or  by  the
  828.          acceptor as specified below.
  829.                a)  If the AARQ  APDU  is  rejected  by  the  ACPM  (i.e.,  an  A-ASSOCIATE
  830.                   indication primitive is not issued  to  the  acceptor),  the  value  of
  831.                   ╗rejected (permanent)½ or ╗rejected (transient)½  is  assigned  by  the
  832.                   ACPM.
  833.                b)  Otherwise, the value is determined by the Result paramet r  of  the  A-
  834.          ASSOCIATE response primitive.
  835.                For the requesting ACPM: This value is used to determine the value  of  the
  836.          Result parameter of the A-ASSOCIATE confirm primitive.
  837.          7.1.5.8   Result Source-Diagnostic
  838.                This field contains both the Result Source value and the Diagnostic value.
  839.          7.1.5.8.1 Result Source value
  840.                For the accepting ACPM: This value is assigned by  the  ACPM  as  specified
  841.          below.
  842.                a)  If the AARQ  APDU  is  rejected  by  the  ACPM  (i.e.,  an  A-ASSOCIATE
  843.                   indication primitive is not issued to the  acceptor),  it  assigns  the
  844.                   value ╗ACSE service-provider½.
  845.                b)  Otherwise, the ACPM assigns the value ╗ACSE service-user½.
  846.                For the requesting ACPM: This value is used to determine the value  of  the
  847.          Result Source parameter of the A-ASSOCIATE confirm primitive.
  848.          7.1.5.8.2 Diagnostic value
  849.                For the accepting ACPM: This value is determined by  the  ACPM  or  by  the
  850.          acceptor as specified below.
  851.                a)  If the AARQ  APDU  is  rejected  by  the  ACPM  (i.e.,  an  A-ASSOCIATE
  852.                   indication primitive is not issued to the  acceptor),  the  appropriate
  853.                   value is assigned by the ACPM.
  854.                b)  Otherwise, the value is determined  by  the  value  of  the  Diagnostic
  855.                   parameter of the A-ASSOCIATE  response  primitive.  If  the  Diagnostic
  856.                   parameter is not included on the response primitive, the  ACPM  assigns
  857.                   the value of ╗null½.
  858.                For the requesting ACPM: This value is used to determine the value  of  the
  859.          Diagnostic parameter of the A-ASSOCIATE confirm  primitive,  unless  it  has  the
  860.          value of ╗null½. In this case, a Diagnostic value is not included.
  861.          7.1.5.9   Implementation Information
  862.  
  863.  
  864.  
  865.  
  866.  
  867.          PAGE22        Rec. X.227
  868.  
  869.  
  870.                 For the accepting ACPM: The value assigned  to  this  field  is  determined
  871.           within the implementation of the ACPM. It contains information  specific  to  the
  872.           individual implementation of that ACPM. It is not used in negotiation.
  873.                 For the requesting ACPM: This field does not affect the  operation  of  the
  874.           ACPM. Any use depends  on  a  common  understanding  between  the  accepting  and
  875.           requesting ACPMs.
  876.           7.1.5.10  User Information
  877.                 For the accepting ACPM: This value is determined by the value of  the  User
  878.           Information parameter of the A-ASSOCIATE response primitive.
  879.                 For the requesting ACPM: This value is used to determine the value  of  the
  880.           User Information parameter of the A-ASSOCIATE confirm primitive.
  881.           7.1.6  Collisions and interactions
  882.           7.1.6.1   A-ASSOCIATE service
  883.                 For a given ACPM, an A-ASSOCIATE collision cannot occur (see S 6.4.6).  For
  884.           a given AE, two distinct ACPMs would be involved which represent  the  processing
  885.           for two distinct associations:
  886.                 a)  an ACPM which processes the initial A-ASSOCIATE request primitive which
  887.                      results in the sending of an AARQ as user data on a  P-CONNECT  request
  888.                      primitive; and
  889.                 b)  an ACPM which processes the subsequently received  AARQ  APDU  as  user
  890.                      data on a P-CONNECT indication primitive.
  891.           7.1.6.2   A-ABORT, P-U-ABORT, or P-P-ABORT service
  892.                 If an ACPM receives and A-ABORT request primitive, a  P-U-ABORT  indication
  893.           primitive, or a  P-P-ABORT  indication  primitive,  it  discontinues  the  normal
  894.           association establishment procedure, and instead  follows  the  abnormal  release
  895.           procedure.
  896.           7.2    Normal release of an association
  897.           7.2.1  Purpose
  898.                 This procedure is used for the normal release of an association  by  an  AE
  899.           without loss of information in transit. It supports the A-RELEASE service.
  900.           7.2.2  APDUs used
  901.                 The normal release procedure uses the  A-RELEASE-REQUEST  (RLRQ)  APDU  and
  902.           the A-RELEASE-RESPONSE (RLRE) APDU. The fields of the RLRQ  APDU  are  listed  in
  903.           Table 4/X.227. The fields of the RLRE APDU are listed in Table 5/X.227.
  904.                                                  TABLE 4/X.227
  905.                                                RLRQ APDU fields
  906.                    Field name            Presence    Source      Sink 
  907.           Reason                             U        req       ind 
  908.           User Information                   U        req       ind 
  909.                                                  TABLE 5/X.227
  910.                                                RLRE APDU fields
  911.                    Field name            Presence    Source      Sink 
  912.           Reason                             U        rsp       cnf 
  913.           User Information                
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.                                                                        Rec. X.227       PAGE1
  940.  
  941.  
  942.                                             U        rsp       cnf 
  943.                7.2.3  Normal release procedure
  944.                This procedure is driven by the following events:
  945.                a)  an A-RELEASE request primitive from the requestor;
  946.                b)  an RLRQ APDU as user data on a P-RELEASE indication primitive;
  947.                c)  an A-RELEASE response primitive from the acceptor, or
  948.                d)  an RLRE APDU as user data on P-RELEASE confirm primitive.
  949.          7.2.3.1   A-RELEASE request primitive
  950.          7.2.3.1.1 When an A-RELEASE request primitive is received, the ACPM sends an RLRQ
  951.          APDU as user data on a P-RELEASE request primitive using the parameters from  the
  952.          A-RELEASE request primitive.
  953.                Note - The requestor is required to meet  the  presentation  (and  session)
  954.          requirements in order to issue an A-RELEASE request  primitive  (see  S  6.2  and
  955.          6.3).
  956.          7.2.3.1.2 The requesting ACPM now waits for a  primitive  from  the  presentation
  957.          service-provider. It does not accept any primitives from the requestor other than
  958.          an A-ABORT request primitive.
  959.          7.2.3.2   RLRQ APDU
  960.                When the accepting ACPM receives the RLRQ APDU as user data on a  P-RELEASE
  961.          indication  primitive,  it  issues  an  A-RELEASE  indication  primitive  to  the
  962.          acceptor. It does not accept any ACSE primitives from its service-user other than
  963.          an A-RELEASE response primitive or an A-ABORT request primitive.
  964.          7.2.3.3   A-RELEASE response primitive
  965.                The Result parameter on the A-RELEASE response primitive specifies  whether
  966.          the acceptor accepts or rejects the release of  the  association.  The  accepting
  967.          ACPM forms an RLRE APDU from the response primitive parameters. The RLRE APDU  is
  968.          sent as user data on a P-RELEASE response primitive.
  969.                a)  If the acceptor accepted the release, the Result paramet r  of  the  P-
  970.                   RELEASE  response  primitive  has   a   Result   parameter   value   of
  971.                   ╗affirmative½. The association is released.
  972.                b)  If the acceptor rejected the release, the Result paramet r  of  the  P-
  973.                   RELEASE response primitive has a Result parameter value of  ╗negative½.
  974.                   The association continues.
  975.                Note - To give a negative response, the acceptor is required  to  meet  the
  976.          related presentation (and session) requirements (see S 6.3).
  977.          7.2.3.4   RLRE APDU
  978.                The requesting ACPM receives a P-RELEASE confirm  primitive  containing  an
  979.          RLRE APDU from its peer. The Result parameter on the P-RELEASE confirm  primitive
  980.          specifies either that the acceptor agrees or disagrees that the  association  may
  981.          be released. The requesting ACPM forms an A-RELEASE confirm  primitive  from  the
  982.          RLRE APDU fields.
  983.                a)  If the Result parameter on the P-RELEASE  confirm  primitive  specifies
  984.                   ╗affirmative½, the association is released.
  985.                b)  If the Result parameter on the P-RELEASE  confirm  primitive  specifies
  986.                   ╗negative½,  the  association  continues.  The  requesting  ACPM  again
  987.                   accepts primitives from its service-user.
  988.          7.2.3.5   A-RELEASE service collision
  989.          7.2.3.5.1 An A-RELEASE service collision occurs when an ACPM has sent out an RLRQ
  990.          APDU as the user data of a P-RELEASE request primitive (as a result of  receiving
  991.          an A-RELEASE request primitive from its service-user). Instead of  receiving  the
  992.          expected RLRE APDU as uset data on a P-RELEASE confirm primitive from  its  peer,
  993.          it receives an RLRQ APDU as the user data of a P-RELEASE indication primitive.
  994.          7.2.3.5.2 The ACPM issues an A-RELEASE indication primitive to its  service-user.
  995.          The procedure then followed by an ACPM depends on whether  its  service-user  was
  996.          the association-initiator or the association-responder.
  997.                a)  For the association-initiator:
  998.                    1)  The ACPM waits for an A-RELEASE response primitive from its service
  999.                       user. When it receives the response primitive,  it  forms  an  RLRE
  1000.                       APDU from the response primitive's parameters. The RLRE is sent  as
  1001.                       user data  on  a  P-RELEASE  response  primitive.  The  association
  1002.                       continues.
  1003.                    2)  This ACPM now waits for an RLRE from its peer as user data on a  P-
  1004.                       RELEASE confirm primitive. It does not accept  any  primitive  from
  1005.                       its service-user other than an A-ABORT request primitive.
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.          PAGE22        Rec. X.227
  1012.  
  1013.  
  1014.                    3)  When the ACPM receives the RLRE,  it  forms  an  A-RELEASE  confirm
  1015.                       primitive from the RLRE fields and isssues it to its  service-user.
  1016.                       The association is released.
  1017.                In summary, the sequence of events which drive the ACPM of the association 
  1018.          initiator are:
  1019.                - A-RELEASE request primitive;
  1020.                - RLRQ APDU (causing the collision);
  1021.                - A -RELEASE response primitive; and finally
  1022.                - RLRE APDU.
  1023.                b)  For the association-responder:
  1024.                    1)  The ACPM waits for an RLRE from its pe r  as  user  data  on  a  P-
  1025.                       RELEASE confirm primitive. It does not accept a primitive from  its
  1026.                       service-user other than an A-ABORT request primitive.
  1027.                    2)  When this ACPM receives the RLRE, it  forms  an  A-RELEASE  confirm
  1028.                       primitive from the RLRE fields. The association continues.
  1029.                    3)  The ACPM now waits for an A-RELEASE  response  primitive  from  its
  1030.                       service-user. When it receives the response primitive, it forms  an
  1031.                       RLRE APDU from the respone primitive's parameters. The RLRE is sent
  1032.                       as user data on a P-RELEASE response primitive. The association  is
  1033.                       released.
  1034.                In summary, the sequence of events which drive the ACPM of the association 
  1035.          responder are:
  1036.                -   A-RELEASE request primitive;
  1037.                -   RLRQ APDU (causing the collision);
  1038.                -   RLRE APDU; and finally
  1039.                -   A-RELEASE response primitive.
  1040.          7.2.4  Use of the RLRQ APDU fields
  1041.                The RLRQ APDU fields are used by the  requesting  and  accepting  ACPMs  as
  1042.          specified below.
  1043.          7.2.4.1   Reason
  1044.                For the requesting ACPM: This value is  determined  by  the  value  of  the
  1045.          Reason parameter of the A-RELEASE request primitive.
  1046.                For the accepting ACPM: This value is used to determine the  value  of  the
  1047.          Reason parameter of the A-RELEASE indication primitive.
  1048.          7.2.4.2   User Information
  1049.                For the requesting ACPM: This value is determined by the value of the  User
  1050.          Information parameter of the A-RELEASE request primitive.
  1051.                For the accepting ACPM: This value is used to determine the  value  of  the
  1052.          User Information parameter of the A-RELEASE indication primitive.
  1053.          7.2.5  Use of the RLRE APDU fields
  1054.                The RLRE APDU fields are used by the  accepting  and  requesting  ACPMs  as
  1055.          specified below.
  1056.          7.2.5.1   Reason
  1057.                For the accepting ACPM: This value  is  determined  by  the  value  of  the
  1058.          Reason parameter of the A-RELEASE response primitive.
  1059.                For the requesting ACPM: This value is used to determine the value  of  the
  1060.          Reason parameter of the A-RELEASE confirm primitive.
  1061.          7.2.5.2   User Information
  1062.                For the accepting ACPM: This value is determined by the value of  the  User
  1063.          Information parameter of the A-RELEASE response primitive.
  1064.                For the requesting ACPM: This value is used to determine the value  of  the
  1065.          User Information parameter of the A-RELEASE confirm primitive.
  1066.          7.2.6  Collisions and interactions
  1067.          7.2.6.1   A-RELEASE service
  1068.                For a given ACPM, an A-RELEASE service collision can occur. The  processing
  1069.          for such a collision is described in S 7.2.3.5.
  1070.                Note - An A-RELEASE service collision can only occur if no  session  tokens
  1071.          were selected for the association.
  1072.          7.2.6.2   A-ABORT service, P-U-ABORT, or P-P-ABORT service
  1073.                If an ACPM receives an A-ABORT request primitive,  a  P-U-ABORT  indication
  1074.          primitive,  or  a  P-P-ABORT  indication  primitive,  it  disrupts   the   normal
  1075.          association  release  procedure,  and  instead  follows  the   abnormal   release
  1076.          procedure.
  1077.          7.3    Abnormal release of an association
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.                                                                       Rec. X.227       PAGE1
  1084.  
  1085.  
  1086.          7.3.1  Purpose
  1087.                The Abnormal Release procedure can be used at any time to force the  abrupt
  1088.          release of the association by a requestor in either AE, by either ACPM or by  the
  1089.          presentation service-provider. When the abnormal  release  procedure  is  applied
  1090.          during  an  attempt  to  establish  an  association,  the  association   is   not
  1091.          established. The abnormal release procedure supports the  A-ABORT  and  A-P-ABORT
  1092.          services.
  1093.          7.3.2  APDUs used
  1094.                The abnormal release procedure uses the A-ABORT (ABRT) APDU. The fields  of
  1095.          the ABRT APDU are listed in Table 6/X.227.
  1096.                Note - No APDUs are defined for the A-P-ABORT service since it is  directly
  1097.          mapped from the P-P-ABORT service.
  1098.                                                 TABLE 6/X.227
  1099.                                               ABRT APDU fields
  1100.                   Field name            Presence    Source      Sink 
  1101.          Abort Source                       M         sp        ind 
  1102.          User Information                   U        req       ind 
  1103.                7.3.3  Abnormal release procedure
  1104.                This procedure is driven by the following events:
  1105.                a)  an A-ABORT request primitive from the requestor;
  1106.                b)  a P-U-ABORT indication primitive;
  1107.                c)  a P-P-ABORT indication primitive; or
  1108.                d)  a protocol error detected by an ACPM.
  1109.          7.3.3.1   A-ABORT request primitive
  1110.                When an ACPM receives an A-ABORT request primitive from  its  service-user,
  1111.          the processing which it performs depends on the version of the underlying session
  1112.          protocol (X.225) which supports the association as specified below.
  1113.                a)  For version 1, the ACPM does not send any of its APCI to its  peer.  It
  1114.                   simply issues a P-U-ABORT request primitive. If the user information is
  1115.                   included on the A-ABORT request  primtive,  that  user  information  is
  1116.                   passed as user data on the P-U-ABORT request primitive. The association
  1117.                   is released.
  1118.                b)  For other versions, the ACPM sends an ABRT APDU as user data on a  P-U-
  1119.                   ABORT request primitive. The Abort Source field is specified  as  ╗ACSE
  1120.                   service-user½. If the User Information parameter is included on t e  A-
  1121.                   ABORT  request  primitive,  it  is  included  in  the  ABRT  APDU.  The
  1122.                   association is released.
  1123.          7.3.3.2   P-U-ABORT indication primitive
  1124.                When an ACPM receives a  P-U-ABORT  indication  primitive,  the  User  Data
  1125.          parameter may contain6 an ABRT APDU:
  1126.                a)  If the indication primitive does not contain an  ABRT  APDU,  the  ACPM
  1127.                   issues an A-ABORT indication primitive with the Abort Source  parameter
  1128.                   specified as ╗ACSE service-user½. If a user data is contained on the P 
  1129.                   U-ABORT indication primitive, it is included as  the  User  Information
  1130.                   parameter of the  A-ABORT  indication  primitive.  The  association  is
  1131.                   released.
  1132.                b)  If the indication primitive does contain an ABRT ADPU, the ACPM  issues
  1133.                   an A-ABORT indication primitive using the Abort  Source  field  of  the
  1134.                   ABRT APDU. If a User Information field is contained in the  ABRT  APDU,
  1135.                   it is included on the A-ABORT indication primitive. The association  is
  1136.                   released.
  1137.          7.3.3.3   P-P-ABORT indication primitive
  1138.                When an ACPM receives a P-P-ABORT indication primitive, the ACPM issues  an
  1139.          A-P-ABORT indication primitive to the acceptor. The association is released.
  1140.          7.3.3.4   Protocol errors
  1141.          7.3.3.4.1 Two types of ACSE protocol errors are possible:
  1142.                a)  for a particular ACPM state, an unexpected APDU is received; or
  1143.                b)  an invalid field is encountered during the processing  of  an  incoming
  1144.          APDU (see S 7.4).
  1145.          7.3.3.4.2 If an unexpected APDU is received, the abnormal  release  procedure  is
  1146.  
  1147.          6  If an association is supported by version 1 of the session-protocol (Rec. X.225),   the
  1148.            User Data parameter does not contain an ABRT ADPU (see S 7.3.3.1). The  absence  of  an
  1149.            APDU in this situation does not imply that the application is operating  n  the  X.410-
  1150.            1984 mode. 
  1151.  
  1152.  
  1153.  
  1154.  
  1155.          PAGE22        Rec. X.227
  1156.  
  1157.  
  1158.          invoked. If an invalid field is detected by an ACSE procedure that  procedure  is
  1159.          disrupted and the abnormal release procedure is invoked.
  1160.          7.3.3.4.3 As part of the abnormal release procedure, the ACPM issues  an  A-ABORT
  1161.          indication primitive to its service-user, unless the error  occurred  during  the
  1162.          association establishment procedure7 as the result of receiving an invalid A   
  1163.          (see S 7.4). If an indication primitive is issued, the value of the Abort  Source
  1164.          is ╗ACSE service-provider½. The User Information parameter is not used.
  1165.          7.3.3.4.4 The subsequent ACPM processing performed depends on the version of  the
  1166.          underlying session-protocol (X.225) which supports the association  as  specified
  1167.          below.
  1168.                a)  For version 1, the ACPM issues a P-U-ABORT request primitive.  No  user
  1169.          information is included.
  1170.                b)  For other versions, the ACPM sends an ABRT APDU as user data on a  P-U-
  1171.                   ABORT request primitive. The Abort Source field is specified  as  ╗ACSE
  1172.                   service-provider½. The User Information field is not used.
  1173.          7.3.3.4.5 In either case, the association is released.
  1174.          7.3.4  Use of the ABRT APDU fields
  1175.                The ABRT APDU fields are used by the  requesting  and  accepting  ACPMs  as
  1176.          specified below.
  1177.          7.3.4.1   Abort Source
  1178.                For the requesting ACPM: This value is assigned by the  ACPM  as  specified
  1179.          below.
  1180.                a)  If the ACPM initiated the abort procedure, the ACPM assigns  the  value
  1181.          of ╗ACSE service-provider½.
  1182.                b)  Otherwise, the ACPM assigns the value of ╗ACSE service-user½.
  1183.                For the accepting ACPM: This value is used to determine the  value  of  the
  1184.          Abort Source parameter of the A-ABORT indication primitive.
  1185.          7.3.4.2   User Information
  1186.                For the requesting ACPM: This value is determined by the value of the  User
  1187.          Information parameter of the A-ABORT request primitive.
  1188.                For the accepting ACPM: This value is used to determine the  value  of  the
  1189.          User Information parameter of the A-ABORT indication primitive.
  1190.          7.3.5  Collisions and interactions
  1191.                The abnormal release procedure may  be  used  whenever  an  association  is
  1192.          established, is in the  process  of  being  established,  or  is  being  normally
  1193.          released. This procedure disrupts any other currently acti e  procedure.  A  P-P-
  1194.          ABORT indication primitive can disrupt the A-ABORT procedure with loss of t e  A-
  1195.          ABORT information. Collisions  of  ABRT  APDUs  are  governed  by  the  P-U-ABORT
  1196.          services (X.216).
  1197.          7.4    Rules for extensibility
  1198.          7.4.1  When processing an incoming AARQ, the accepting ACPM shall:
  1199.                a)  ignore all tagged values which are not defined in the  abstract  syntax
  1200.          of this Recommendation; and
  1201.                b)  ignore all unknown bit name assignments within a bit string.
  1202.          7.4.2  After the association has been established or during the establishment  of
  1203.          an association, only those ACSE APDUs and related  ADPU  fields  defined  in  the
  1204.          ASN.1 description of the negotiated  version  of  this  Recommendation  shall  be
  1205.          issued.
  1206.          7.4.3  A received APDU or field within an APDU which is not defined in the  ASN.1
  1207.          description of the negotiated version of this Recommendation shall be treated  as
  1208.          a protocol error.
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.          7  Since an A-ASSOCIATE   indication  primitive  is  not  issued,  an  A-ABORT  indication
  1222.            primitive would have no meaning, and, therefore, it is not issued. 
  1223.  
  1224.  
  1225.  
  1226.  
  1227.                                                                       Rec. X.227       PAGE1
  1228.  
  1229.  
  1230.